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Description 
Status monitoring system 

Continuity statement 

[0001] This is a continuation-in-part of US appl. no. 09/704,505, 
filed November 1, 2000, which claims priority from US 
appl. no. 60/162,653, filed November 1, 1999, now ex- 
pired, each of which is incorporated herein by reference 

for all purposes. 
Background 

[0002] The Internet has given rise to opportunities for ready 

availability of information that was heretofore only avail- 
able by more cumbersome means such as telephone calls 
and inquiries presented in person or by written corre- 
spondence. Shippers provide package tracking informa- 
tion on web sites; for example, the US Postal Service pro- 
vides tracking information regarding Express Mail pack- 
ages on a web site. The US Patent and Trademark Office 
provides trademark status information on a web site 
called TARR (Trademark Application and Registration Re- 



trieval). The Trademark Trial and Appeal Board of the US 
Patent and Trademark Office provides status information 
for appeals and inter partes matters, and provides images 
of filed papers, through its TTABVUE system. The US 
Patent and Trademark Office provides patent application 
status information on a web site called PAIR (Patent Appli- 
cation Information Retrieval), and provides images of filed 
papers through the Image File Wrapper (IFW) system. The 
PAIR site is provided with a means for establishing a cryp- 
tographically secure communications channel so that third 
parties are unlikely to be able to intercept the patent ap- 
plication status information electronically. The US federal 
court system provides status of federal litigations through 
its web-based PACER (public access to court electronic 
records) system, and provides images of filed papers. The 
Canadian Intellectual Property Office (ClPO) provides 
trademark status information on its Strategis web site. 
The European Patent Office provides patent status infor- 
mation, including images, on its EPOLINE web site. The 
Organization for Harmonization in the Internal Market 
(OHIM) provides information on the status of Community 
Trade Mark (CTM) applications. The World Intellectual 
Property Organization (WlPO) provides information on the 



status of international trademarl< applications under the 
Madrid Protocol and the Madrid Agreement in its web- 
based Madrid Express database. WlPO also provides infor- 
mation on international patent applications under the 
Patent Cooperation Treaty (PCT) in its IPDL. 
[0003] Unfortunately, many of these web sites have the drawback 
that it is extremely tedious to check the status of many 
records. On the web site of the US Postal Service, if it is 
desired to check the status of several Express Mail pack- 
ages, the user is forced to hand-type each of the tracking 
numbers one by one into the server. This not only takes 
time but also presents the risk that the user may, through 
inadvertence, type a tracking number incorrectly. A fur- 
ther risk is that the user, checking a list multiple tracking 
numbers, may forget to check one of the tracking num- 
bers. 

[0004] Yet a further drawback is that the user is reduced to hav- 
ing to manually (visually) check the present status (as re- 
ported on the web site) with the previous status (perhaps 
reported on a paper printout from a previous status 
check). This task is tedious, requires awkward paper 
records, and is error-prone. A human user might not no- 
tice that some obscure item of status has changed since 



the previous status check. 

[0005] On the TARR web site, the user is lil<ewise forced to type 
in serial numbers or registration numbers one by one. 
Each one can be mistyped through inadvertence. Serial 
numbers or registration numbers can be inadvertently 
omitted, leading to the unfortunate result that the status 
is not checked. When status reports are provided by the 
TARR server, the reports contain lots of information and it 
is tedious and error-prone to check manually for changes 
in status from a previous status check. 

[0006] On the PAIR web site, the user is likewise forced to type in 
serial numbers or patent numbers one by one. Each one 
can be mistyped through inadvertence. Serial numbers or 
patent numbers can be inadvertently omitted, leading to 
the unfortunate result that the status is not checked. 
When status reports are provided by the PAIR server, the 
reports contain lots of information and it is tedious and 
error-prone to check manually for changes in status from 
a previous status check. A user may wish to check for new 
records that are available from the server that match a 
particular customer number, and this check may result in 
identifying new records that need status updates. This 
step is also tedious and risks error, for example if there is 



new record and if the user fails to notice that a record is 
new. 

[0007] Some of these web sites provide images of filed docu- 
ments. Such web sites include the EPOLINE system, the 
PACER system, the TTABVUE system, and the US Patent 
and Trademark Office's IFW (image file wrapper) system 
which is reachable through the PAIR system. In these sys- 
tems as they now exist, it is extremely tedious to learn 
when a new image has been added to a record within the 
system, and it is tedious to obtain the image and to for- 
ward it to a particular person who may wish to review the 
image. 

[0008] All of these steps take a very long time. A US patent law 
firm with a modest-sized docket (e.g. 200 patent files and 
200 trademark files) can spend an entire day trying to ob- 
tain status changes on its pending files, and tracking the 
status of the Express Mail packages which it has sent to 
the Patent Office. 

[0009] There is thus a great need for a method and system which 
avoid tedium, which are not error-prone, and which ob- 
tain their results quickly. 
Summary of the invention 

[0010] A method is described for use with a server serving re- 



quested records among a multiplicity of records, and with 
a predetermined list of record identifiers, and with a first 
file containing information about records corresponding 
to the record identifiers. The method comprises the steps 
of: selecting at least two of the record identifiers from the 
list; for each one record identifier of the record identifiers: 
presenting a request to the server with respect to the 
record identifier; receiving a record from the server, said 
record corresponding to the record identifier; parsing the 
record, thereby deriving received information of interest 
from the record; comparing the received information of 
interest with corresponding information in the first file; 
and annunciating any difference between the received in- 
formation of interest and the corresponding information 

in the first file. 
Description of the drawing 

[0011] The invention is described with respect to a drawing in 

several figures, of which: 
[0012] Fig. 1 shows a system according to the invention; and 

[0013] Fjg, 2 shows a system according to the invention in the 

particular case of a system employing a cryptographically 
secure communications channel. 



Detailed description 

[0014] A portion of Fig. 1 can be used to describe tlie prior art. A 
hypertext transfer protocol (HTTP) server 10 provides in- 
formation via tlie Internet 12, drawn from a database 11. 
The HTTP server may be for example the above- 
mentioned IPDL, TTABVUE, PACER, PAIR, TARR, or USPS 
servers. 

[0015] In the system according to the invention, a client 13 is 
preferably a personal computer located at a user's 
premises, for example an intellectual property law firm 
omitted for clarity in Fig. 1. The client 13 runs software 
according to the invention which performs most of the 
steps described herein. 

[0016] As mentioned earlier, the server 10 serves requested 

records among a multiplicity of records from a database 
11. The client 13 draws upon a predetermined list of 
record identifiers stored in a data file 14. For convenience 
the file 14 may also contain information about records 
corresponding to the record identifiers. As mentioned be- 
low, however, the invention does not require that the list 
of record identifiers be stored in the same data file as the 
information about records. 

[0017] The client 13 then performs an update. This update may 



be manually initiated by a user, or may be an automated 
process such as a Windows service or a Linux cron job. 
The client 13 selects at least one record identifier, though 
in most cases the client 13 will select at least two of the 
record identifiers from the list, and in some cases the 
client 13 will select all records matching a criterion or may 
match all records in the database. 

[0018] In a preferred embodiment, each record identifier has as- 
sociated with it a "frequency" relating to how often it is 
desired to perform an update. This may be daily, weekly, 
monthly, or never, in an exemplary system. The client 13 
will then select records based on whether each record is 
scheduled for an update on the present day. 

[0019] The client 13, for each one record identifier of the record 
identifiers, performs a number of steps. It presents a re- 
quest to the server with respect to the record identifier. It 
receiving a record from the server, the record correspond- 
ing to the record identifier. (Another possible outcome is 
a timeout if, for example, the server fails to respond 
timely.) 

[0020] The client 13 parses the record, thereby deriving received 
information of interest from the record. This is a nontrivial 
task, especially considering that the US Postal Service or 



the US Patent and Trademark Office may, without warning, 
change the format or syntax of its web page status re- 
ports, thus crippling the status monitoring software ac- 
cording to the invention. Parsed information is obtained 
from the HTTP response. For example, in the case of a 
trademark record, the parsing software extracts the filing 
date, the examining group, the expected publication date, 
the most recent status, and other information. In the case 
of a patent record, the parsing software extracts the ex- 
aminer's name, the group art unit, the foreign priority 
data, the continuity data, and the most recent status, 
among other information. 

[0021] The client 13 then compares the received information of 
interest with corresponding information in the first file 14. 
It annunciates any difference between the received infor- 
mation of interest and the corresponding information in 
the first file 14. This is preferably done by sending email 
to predetermined recipients and by flagging such events 
by means of distinctive characters on a status display 
screen and in the HTML and XML files mentioned below. 

[0022] In the general case, the client 13 replaces the information 
in the first file 14 with the received information of inter- 
est. This means that the system has current status infor- 



mation which may be compared on future days with status 
information retrieved in the future. 

[0023] It will be appreciated that the steps carried out by the 
client 13 are not performed manually by a human user 
operating a web browser and typing characters into the 
web browser. Instead and in contrast, the steps carried 
out by the client 13 are performed by means of a stored 
program in appropriate hardware such as a general-pur- 
pose personal computer. 

[0024] In the case of a system that makes images available, the 
client 13 checks to see what images were previously listed 
as being available, and if one or more additional images 
now are listed as being available, then the system down- 
loads the new images. These images are preferably 
emailed to particular recipients. For example the client 13 
may have a database of records listing the files to be 
monitored, and each record may have a respective email 
address representing a recipient who is to receive updates 
regarding that record, including new images for that 
record in the case of a system providing images. More 
than one email address may be stored so that the update 
may be emailed to two or more interested persons. 

[0025] It is desirable, in the case of a multipage document, to 



collect the images of the pages of the document and to 
stitch the images together into a multipage file such as a 
multipage TIF file or a multipage PDF file. The multipage 
file is preferably stored for future reference and is prefer- 
ably emailed to an interested person or persons. 

[0026] It is desirable in addition to have the client 13 create or 

update an extensible markup language (XML) file 16 which 
may be processed by other software 20. In addition, it is 
desired to create or update a hypertext markup language 
(HTML) file 15 containing the information in the first file 
14 but in HTML form. Such a file is preferably then served 
by means of a web server 17, via an intranet 18, to clients 
19 within the intellectual property law firm, again omitted 
for clarity in Fig. 1. 

[0027] Experience shows that the designers of some of the web- 
based systems choose to design their systems so that a 
predictable URL (uniform resource locator) may be used to 
view a particular image. For example in TTABVUE a partic- 
ular image will have the same URL every time a visitor 
saerches for and arrives at the particular image. Substitut- 
ing a different serial number or proceeding number in the 
URL will find a corresponding image in the records of an- 
other serial number or proceeding. From the user's point 



of view this is a very user-friendly quality of the design of 
the system. 

[0028] Even if a URL is not particularly predictable, it is extremely 
desirable that the the URL be time-independent and ses- 
sion-independent. By this what is meant is that a user 
could "bookmark" a URL for an image, and return hours or 
days later, and the bookmark would still work. By this 
what is also meant is that a user could send the URL to 
someone else by email, or could use the URL in a web link, 
and the URL and link would work just as well even days 
later. From the user's point of view this is a very important 
quality for a user-friendly web site. 

[0029] Some systems, in contrast, have long URLs (dozens or 
even hundreds of characters in length) which contain 
dozens of seemingly random characters. Experience often 
shows that such URLs are neither time-independent nor 
session-independent. If the user bookmarks such a URL, it 
won't work the next day. If the user emails the URL to a 
colleague, the colleague will get no benefit from the URL 
as it won't work even five minutes later. Such a URL is typ- 
ically tied to session-specific information such as "cook- 
ies" which explains why it does not work for the colleague. 
Experience shows that with such URLs it is generally im- 



possible to substitute one serial number for another 
within the URL to obtain any meaningful result for the new 
serial number. 

[0030] In the case where the URL is user-friendly (time- and ses- 
son-independent) the client 13 may make great benefit 
from such a URL. For example, when the client 13 learns 
that a new image is available, the client 13 may desirably 
email the link (the URL) to a user. The user can then read 
the email message, see the link, click on it, and then view 
the image. This saves having to email the image file itself, 
which takes up space in a mail spool or in a user's email 
in-box. In addition, in the HTML page or XML page gener- 
ated by the client 13, the URL can be embedded into the 
HTML or XML page which allows a user who views the 
HTML or XML to click on the link and to view the new im- 
age. 

[0031] In the case where a system has "unfriendly" URLs (e.g. 
URLs that don't work more than once and that are ses- 
sion-dependent or time-dependent or both) it does no 
good to attempt to email a system image URL to a user, 
and it does no good to attempt to embed the URL into an 
HTML or XML page. When the client 13 is used with such a 
system, the preferable approach is simply to download the 



image and to store it in a local server such as a local web 
server. The operator of the local web server can establish 
user-friendly URLs for such image files. This can be done 
manually by a webmaster or can be done automatically 
and "on the fly" by a system such as a PHP program. Such 
a URL can be emailed to a colleague or user and it will 
work days or months later. 

[0032] In the HTML or XML page created by the client 13, it is 
preferable for each image link to provide a column indi- 
cating the date on which the image file was downloaded 
or first made available by "friendly" URL link. 

[0033] Those skilled in the art will appreciate that the protocol 
used between client 13 and server 10 are necessarily de- 
termined by the server 10. In the present day, the served 
records are in the hypertext markup language file and the 
server 10 is a hypertext transfer protocol server, which 
means that the client 13 must be an HTTP client receiving 
and parsing HTML data. If the server 10 were serving XML 
records, then the client 13 would have to receive and 
parse XML data. While the latter is desirable from the pro- 
gramming point of view, the designer of the client 13 is 
constrained by the decisions made by the operator of the 
server 10, for example the US Postal Service or the United 



States Patent and Trademark Office. 

[0034] Fig. 2 sliows iiow tlie system of Fig. 1 clianges wlien a 
cryptograpliically secure communications linic with the 
server is employed. In the case of the PAIR server, the US 
Patent and Trademark Office has determined that the user 
will employ software called USPTO Direct 26 which, to- 
gether with corresponding software 25, creates a crypto- 
graphically secure channel 30 between the server 10 and 
the client 13. Those skilled in the art will appreciate that 
the particular cryptographic approach employed is not 
material to the invention, and that other approaches such 
as point-to-point tunneling protocol or SSH protocol 
could Just as well be used, a decision likewise not material 
to the invention. 

[0035] In the case of PAIR, the the record identifiers are patent 
application serial numbers or patent numbers. In the case 
of TARR and the OHIM database and the Strategis trade- 
marks database, the record identifiers are trademark ap- 
plication serial numbers or trademark registration num- 
bers. In the case of Express Mail, the record identifiers are 
package tracking numbers. In the case of TTABVUE, the 
record identifiers are trademark application serial num- 
bers and proceeding numbers. In the case of the Madrid 



Express database, the record identifiers may be interna- 
tional registration numbers. In the case of EPOLINE and 
the WlPO IPDL, the record identifiers are patent applica- 
tion serial numbers. 

[0036] The PAIR server presents an additional opportunity for the 
designer of the client 13. The client 13 can request from 
the server 10 all record identifiers matching a predeter- 
mined criterion such as the customer number, and can 
add any new record identifiers to the predetermined list of 
record identifiers. Stated differently, the client 13 can 
compare the retrieved list of serial numbers and compare 
it with those stored in data file 14, and can annunciate 
new serial numbers. This can happen for example if a 
newly filed patent application finds its way into PAIR, or if 
an existing patent application comes to have the user's 
customer number associated with it. 

[0037] Those skilled in the art will have no difficulty devising ob- 
vious enhancements and improvements to what is de- 
scribed here, all without departing from the invention, all 
of which are intended to be encompassed within the 
claims which follow. 



